AI에게 맡기면 안 되는 코드가 있다?! 생각보다 훨씬 많다 | 매거진에 참여하세요

요즘 개발을 하다 보면, 자연스럽게 이런 순간이 온다.
“이 정도면 AI한테 맡겨도 되겠지?”

그리고 대부분의 경우, 실제로 잘 된다. API 핸들러 하나, 데이터 변환 로직, 반복적인 UI 컴포넌트. AI는 꽤 그럴듯하게 만들어준다.

오히려 내가 직접 짠 코드보다 깔끔해 보일 때도 있다.

문제는 여기서부터다.
AI가 잘해주는 경험이 쌓일수록, ‘어디까지 맡겨도 되는지’에 대한 감각은 점점 흐려진다.

어느 순간엔 거의 반사적으로 프롬프트를 치고, 생성된 코드를 붙여넣고, 테스트만 통과하면 넘어간다. 바쁜 일정 속에서는 그게 합리적인 선택처럼 보인다.

하지만 시간이 지나면, 이상한 패턴이 보이기 시작한다.

항상 같은 영역에서 문제가 터진다. 항상 비슷한 종류의 코드가 발목을 잡는다. 그리고 그 코드들을 다시 들여다보면, 공통점이 하나 있다.

“이건 처음부터 사람이 끝까지 책임졌어야 했던 코드다.”

AI에게 맡기면 안 되는 코드는, 기술적으로 어려운 코드만을 의미하지 않는다.

오히려 겉보기엔 단순한데, 맥락과 판단이 중요한 코드들이 가장 위험하다. 그런 코드들은 정답이 하나가 아니고, 선택의 결과가 시스템 전체에 영향을 미친다.

AI는 이 선택의 무게를 모른다.

1. 인증과 권한 로직

AI는 로그인, 토큰 검증, 권한 체크 코드를 정말 쉽게 만들어준다.

문제는 그 코드가 “동작하는 것”과 “안전한 것” 사이의 차이를 잘 설명해주지 않는다는 점이다.

예를 들어, 어떤 API는 관리자만 접근할 수 있어야 한다.

어떤 API는 읽기만 허용돼야 하고, 어떤 조건에서는 임시 권한을 줘야 한다.

이건 문법 문제가 아니다.
비즈니스 규칙이고, 사고가 났을 때의 책임 문제다.

AI가 만들어준 권한 체크는 대부분 일반적인 패턴에 머문다.

하지만 실제 서비스에서는 예외가 늘 규칙을 이긴다.

특정 파트너에게만 열어둔 엔드포인트, 레거시 사용자에 대한 임시 처리, 운영 중에 추가된 조건들. 이런 맥락을 모른 채 생성된 코드는, 언젠가 반드시 틈을 만든다.

2. 데이터 모델과 도메인 로직

AI는 데이터베이스 스키마를 잘 짜준다. 엔티티도 잘 나눈다.

그런데 그 구조가 “우리 서비스가 왜 이렇게 생겼는지”를 반영하는 경우는 거의 없다.

도메인 로직은 결국 질문의 연속이다.
- 이 상태는 언제 유효한가?
- 이 값은 변경 가능해야 하는가?
- 이 이벤트는 되돌릴 수 있는가?

이 질문에 대한 답은 코드 바깥에 있다. 회의 기록, 과거 장애, 고객 클레임, 조직의 결정.

AI는 그걸 모른다. 그래서 도메인 로직을 AI에게 맡기면, 처음엔 깔끔해 보이지만 시간이 갈수록 설명할 수 없는 규칙들이 여기저기 붙는다.

그리고 어느 순간, 아무도 전체를 이해하지 못하는 상태가 된다.

이건 리팩토링으로 쉽게 해결되지 않는다.
처음의 선택이 계속 발목을 잡기 때문이다.

3. 에러 처리와 예외 설계

AI가 만든 에러 처리는 대체로 친절하다.

try-catch가 있고, 에러 메시지도 있다. 로그도 남긴다. 그런데 실제 운영 환경에서 중요한 건, “에러가 났다”는 사실보다 그 에러를 어떻게 다룰 것인가다.

• - 이 에러는 재시도해야 하는가?
  - 사용자에게 노출해도 되는가?
  - 운영자가 바로 알아야 하는가?
  - 아니면 조용히 삼켜야 하는가?

이 판단은 기술 문제가 아니라 서비스 철학의 문제다.

AI는 여기서 항상 안전한 쪽, 혹은 일반적인 쪽을 선택한다.

하지만 우리 서비스에 맞는 선택은 그게 아닐 수 있다. 그리고 이 차이가 쌓이면, 장애 대응이 점점 어려워진다.

4. 성능 및 비용 코드

의외로 많은 사람들이 성능과 비용이 얽힌 코드도 AI에게 맡긴다.

캐시 전략, 쿼리 최적화, 비동기 처리. AI는 그럴듯한 코드를 만들어준다. 하지만 그 코드가 어떤 비용 구조를 만들고 있는지는 설명하지 않는다.

예를 들어, “이 정도면 캐시 붙이면 되겠지”라는 판단.

AI는 캐시를 붙인다. 하지만 그 캐시가 언제 무효화되는지, 트래픽 패턴에 어떤 영향을 주는지, 장애 시 어떤 연쇄 효과가 있는지는 고려하지 않는다.

성능은 언제나 트레이드오프다.
속도를 얻는 대신 무엇을 잃는지, 비용을 줄이는 대신 어떤 리스크를 감수하는지. 이 판단은 숫자와 경험 위에서 내려진다.

AI는 아직 이 영역에서 파트너라기보다는 참고 자료에 가깝다.

5. 시스템의 경계와 구조 결정 코드

마지막으로, 그리고 가장 중요한 영역이 있다.
- 어디까지를 하나의 서비스로 볼 것인가.
- 이 책임은 어디서 끝나야 하는가.
- 이 모듈은 얼마나 독립적이어야 하는가.

이건 코드 몇 줄의 문제가 아니다. 팀의 협업 방식, 배포 전략, 조직 구조까지 영향을 미친다.

이런 결정을 AI에게 맡기면, 구조는 점점 설명하기 어려운 방향으로 간다.

처음엔 편해 보이지만, 시간이 갈수록 “왜 이렇게 나눴지?”라는 질문에 답할 수 없게 된다.

여기까지 읽으면 이런 생각이 들 수도 있다. “그럼 AI는 도대체 어디에 써야 하는 거야?”

답은 의외로 단순하다.

판단이 필요 없는 곳, 책임이 명확하지 않은 곳, 다시 만들어도 되는 곳.
보일러플레이트, 반복 코드, 참고용 구현, 아이디어를 빠르게 검증하는 단계. 이런 영역에서 AI는 최고의 도구다.

반대로,
한 번 잘못 만들면 오래 가는 코드,
서비스의 성격을 규정하는 코드,
사고가 났을 때 설명해야 하는 코드.

이런 코드만큼은, 속도가 조금 느려지더라도 사람이 끝까지 잡아야 한다.

AI 시대의 개발은 “얼마나 많이 맡길 수 있느냐”의 싸움이 아니다.
“어디까지 맡기지 않을 수 있느냐”의 싸움에 가깝다.

모든 코드를 직접 쓸 필요는 없다.

하지만 모든 선택을 이해하지 못한 채 넘겨서도 안 된다.

AI에게 맡기지 말아야 할 코드가 있다는 걸 인식하는 순간,
비로소 AI는 위험한 자동화가 아니라, 강력한 도구가 된다.